专利摘要:
一実施形態では、プロセッサは、プログラマブルマップと回路とを有する。前記プログラマブルマップは、少なくとも1つの命令であって、前記プロセッサが実装している命令セットアーキテクチャのアーキテクチャの変更が定義されているが、前記プロセッサは前記変更を実装してない命令を識別するデータを記憶するように構成されている。前記回路網は、前記命令またはそのメモリオペランドを検出し、ノウングッドコード(KGC)への遷移を発生させるように構成されており、前記KGCは、不正な変更から保護されており、正当な実体から提供されている。前記KGCは、実行されると前記変更をエミュレートするコードを含む。別の実施形態では、集積回路は、少なくとも1つのプロセッサコアと、少なくとも1つの他の回路と、実行のために前記プロセッサコアにKGCを提供するように構成されたKGCソースとを有する。前記KGCは、前記他の回路のためのインタフェースコードを含み、これにより前記プロセッサコアで実行中のアプリケーションが前記KGCを介して前記他の回路とインタフェースする。
公开号:JP2011508308A
申请号:JP2010539422
申请日:2008-12-03
公开日:2011-03-10
发明作者:ローソン アンドリュー;ディー.;ヒルマン ガース;エイチ.;シンプソン ゲーリー;ストロンジン ジェフリー;フィンダイゼン ラルフ
申请人:アドバンスト・マイクロ・ディバイシズ・インコーポレイテッドAdvanced Micro Devices Incorporated;
IPC主号:G06F9-30
专利说明:

[0001] 本発明は、プロセッサおよびコンピュータシステムの分野に関し、より詳細には、プロセッサアーキテクチャの機能拡張を可能にしたり、オンボードデバイスを制御したり、他の用途のためのシステムのノウングッドコードの使用に関する。]
背景技術

[0002] プロセッサは、命令セットアーキテクチャ(ISA)に定義されている命令を実行するように設計されている。ISAは、命令、命令の符号化方式、ならびに命令の実行時に行われる操作を定義している。また、ISAは、一般に、プロセッサの各種の動作モードと、プログラマが、プロセッサ用のプログラムをコーディングして、所望の動作を実現するために必要な他の情報も定義している。つまり、ISAとは、本質的には、実行する命令ストリームを与えられたときの、プロセッサの動作を定義するものである。]
発明が解決しようとする課題

[0003] プログラマは、プロセッサが、ISAに定義された通りに動作することを当てにしているため、ISAの変更は、通常はプログラマ(またはソフトウェア会社)とプロセッサの設計者(または、プロセッサの製造業者)の両者からの多くの意見を取り入れて、慎重に行う必要がある。必要な挙動がプロセッサによって確実に提供されるようにするために、プロセッサは、ISAの変更をハードウェアに実装している必要がある。このため、変更を実装するにはプロセッサの新しいハードウェアを作製する必要があるため、変更の定義は慎重に記述されており、合意が得られていなければならない。後から追加で変更を行うには、ハードウェアの作製が別に必要となる。]
課題を解決するための手段

[0004] 一実施形態では、集積回路は、少なくとも1つのプロセッサコアと、少なくとも1つの他の回路と、実行のために前記プロセッサコアにノウングッドコード(KGC)を提供するように構成されたKGCソースとを有する。前記KGCは、前記他の回路のためのインタフェースコードを含み、これにより、前記少なくとも1つのプロセッサコアで実行中のアプリケーションが、前記KGCを介して前記少なくとも1つの他の回路とインタフェースする。]
[0005] 別の実施形態では、プロセッサは、プログラマブルマップと、前記プログラマブルマップに結合された回路とを有する。前記プログラマブルマップは、少なくとも1つの命令であって、前記プロセッサが実装している命令セットアーキテクチャのアーキテクチャの変更が定義されているが、前記プロセッサは前記変更を実装してない命令を識別するデータを記憶するように構成されている。前記回路網は、前記命令を検出し、ノウングッドコード(KGC)への遷移を発生させるように構成されており、前記KGCは、不正な変更から保護されており、正当な実体から提供されている。前記KGCは、実行されると前記変更をエミュレートするコードを含む。]
図面の簡単な説明

[0006] プロセッサと、関連するノウングッドコード(KGC)とを示すブロック図。
プロセッサおよびKGCの第1の実施形態のブロック図。
プロセッサおよびKGCの第2の実施形態のブロック図。
プロセッサおよびKGCの第3の実施形態のブロック図。
KGCのための遷移メカニズムの第1の実施形態を示すブロック図。
遷移メカニズムの第1の実施形態を実装するプロセッサの一実施形態のブロック図。
KGCのための遷移メカニズムの第2の実施形態を示すブロック図。
遷移メカニズムの第2の実施形態を実装するプロセッサの一実施形態のブロック図。
KGCをデバイスマネージャとして使用するマルチコア集積回路の一実施形態のブロック図。
デバイスマネージャとしてのKGCの一実施形態の動作を示すフローチャート。
リング0を、保護された領域に分割するためのメカニズムとしてKGCを使用する一実施形態のブロック図。
プロセッサを含む集積回路上のプログラマブルロジックと共にKGCを使用する一実施形態のブロック図。]
実施例

[0007] 以下の詳細な説明は添付の図面を参照している。図面の説明は「図面の簡単な説明」に記載されている。]
[0008] 本発明は、さまざまに変形されたり代替形態を取りうるが、その特定の実施形態が、例として図面に図示され、かつ本明細書に詳細に記載される。しかし、図面および詳細な説明は、本発明を開示の実施形態に限定することを意図するものではなく、添付の特許請求の範囲によって定義される本発明の趣旨ならびに範囲に含まれる全ての変形例、均等物および代替例を含むことを意図したものであることが理解されるべきである。]
[0009] 以下の説明では、ノウングッドコード(Known Good Code:KGC)を使用して、プロセッサのアーキテクチャの変更を柔軟に(例えば、KGCの実行により変更をエミュレートすることによって)実装する場合について説明する。また、以下の説明では、KGCの他の用途についても説明する。これらの用途を説明する前に、KGCの概要について記載する。]
[0010] <ノウングッドコード(KGC)の概要>
一般に、「KGC」とは、そのライフタイムにわたって権限のない実体による変更から保護され、正当な実体から提供されるコードを指す。「正当な実体」とは、例えば、プロセッサの製造業者により、信頼できる実体として認められている実体などである。KGCは、変更不能な記憶域にコードを提供することによって変更から保護されており、この記憶域とプロセッサ間の通信メカニズムが何らかの方法で保護されている。別の実施形態では、KGCは、変更可能な記憶域または保護されていない記憶域に提供されるが、実行前に暗号による認証が行われてもよい。]
[0011] KGCは、安全な実行コンピューティング環境(secure execution computing environment:SECE)内で実行されうる。SECEとは、コンピュータで実行中の他のコードが、コード(KGC)と、関連するデータとを変更または検査することができないコンピューティング環境である。SECEは、(例えば電源投入時に)プロセッサハードウェアによって作成されるか、あるいは起動直後に実行されるソフトウェアによって作成され、SECEが作成され、SECE内にKGCが配置されうる。SECEの例としては、例えば、プロセッサのマイクロコードエンジン;ローカルの安全な不揮発性メモリから、プロセッサの命令キャッシュおよびデータキャッシュにKGCをロードし、キャッシュ内にコードおよびデータをロックするプロセッサ;ローカルの不揮発性メモリからKGCを実行する埋め込み型プロセッサまたは実行エンジン、ならびに正当であり権限を有し、場合によっては暗号化されているか、あるいは(例えばマルチチップモジュール内で)物理的に保護されている他のデバイスへの通信インタフェース(存在する場合)などが挙げられる。明確さを期することが適切な場合、KGCは、他のコードを実行しているのと同じプロセッサによって実行される場合は「ネイティブKGC」と呼ばれ、埋込み型プロセッサなどの異なるプロセッサによって実行される場合は「非ネイティブKGC」と呼ばれる。「KGC」との用語が「ネイティブ」または「非ネイティブ」を付けずに用いられる場合、文脈から明らかであるか、あるいは、その文脈では、ネイティブKGC、非ネイティブKGCのいずれも使用することができる。]
[0012] 図1は、一実施形態のプロセッサおよび関連するKGCの概念レベルのブロック図である。図に示すように、プロセッサ10は、KGCソース12と共に設けられる。任意選択で、暗号認証ユニット14および/または変更保護メモリ16が備えられてもよい。プロセッサ10と、KGC(変更保護メモリ16またはKGCソース12のいずれかに存在)との間の通信リンクは保護されている(図1の参照符号18)。] 図1
[0013] プロセッサ10が、保護されたチャンネル18を介してKGCソース12に直接結合され、KGCソース12が変更保護されている(すなわち、KGCソース12を権限のない実体によって変更できない)場合、暗号認証ユニット14を省略してもよい。権限を有する実体には、KGCを作成した実体、場合によっては、プロセッサ10の製造業者が含まれうる。このため、KGCソース12には、コンピュータによってアクセス可能などのようなストレージデバイスが含まれてもよい。]
[0014] プロセッサ10が、保護されたチャンネル18によってKGCソース12と直接結合されていない場合には、KGCは、そのソース12内で、あるいは変更保護メモリ16への転送中に、不正な変更を受ける可能性がある。暗号認証ユニット14は、KGCを認証して、このような変更が行われないことを保証することができる。例えば、暗号認証ユニット14は、プロセッサからの検証信用ルート(root of trust for verification:RTV)を使用して、KGCを認証しうる。各種実施形態では、どのような認証方式を使用してもよい。]
[0015] 正当なKGCは、変更保護メモリ16に記憶され、プロセッサ10は、保護されたチャンネル18を介してKGCを取り出す。一部の実施形態では、KGCソース12から変更保護メモリ16へのチャンネルが保護されており、KGCソース12が変更保護されており、このため暗号認証が不要となりうる。このような実施形態は、例えば、変更保護メモリ16が、KGCソース12よりもアクセスのレーテンシが低いか、あるいは、変更保護以外の何らかの利点(例えば、各プロセッサが、ローカルの変更保護メモリ16を備えるか、またはプロセッサの一部と変更保護メモリ16を共有するマルチプロセッサシステムにおいて、低電力、同時アクセスなど)を提供する場合に実装されうる。]
[0016] 一般に、変更保護メモリ16は、メモリ16の内容を変更する機能が制限されているか、あるいはこのような機能が除外された、どのような種類のメモリでもよい。詳細には、変更保護メモリ16は、メモリの内容を変更する機能を、権限を有する実体のみに制限することができる。変更保護メモリ16は、権限を有する実体のみが内容を変更できるように物理的に分離されるか、あるいは他の何らかの方法(例えばキャッシュメモリへのロックなど)で保護されうる。]
[0017] 図2〜4は、KGCソースの実装方法のいくつかの例を示す。これらの例は、KGCの保護の度合いが異なる実施形態を示すが、網羅的なものではない。図2〜4に示す実施形態のいずれかに、必要に応じて複数のプロセッサが使用されてもよい点に留意されたい。] 図2 図3 図4
[0018] 図2は、プロセッサ10と、KGCを記憶している不揮発性メモリ22とを備える集積回路20の一実施形態のブロック図である。このため、不揮発性メモリ22は、KGCソース12として機能し、プロセッサ10と同じ集積回路20に物理的に設けられるため、変更保護されている。すなわち、不揮発性メモリ22は集積回路20の外部からアクセスできず、メモリ22にアクセスするためのチャンネルは物理的に保護されている。] 図2
[0019] 不揮発性メモリ22は、さまざまな実装を有することができる。例えば、不揮発性メモリ22は、リードオンリーメモリ(ROM)でも、バッテリバックアップRAMまたは半導体メモリでもよい。別の実施形態では、不揮発性メモリ22は、メモリの組合せ(例えば、KGCがロードされロックされるROMまたは他の不揮発性メモリおよびキャッシュメモリなど)でもよい。KGCがキャッシュにロードされ、キャッシュにロックされる場合、他のメカニズムが実装されてもよい(例えば、コヒーレンシを維持するためにロックされたエントリがスヌープされ、コヒーレンシメカニズムによってコード/データの閲覧が阻止されたり、標準的なキャッシュルックアップの一部ではないテストポートおよび他のアクセスポイントが、ロックされたエントリにアクセスするのを禁止するなど)。]
[0020] 図3は、プロセッサ10およびKGCの別の実施形態のブロック図である。図3の実施形態では、(プロセッサ10を1つ以上備える)プロセッサ集積回路24が、不揮発性メモリ22と共にマルチチップモジュール(MCM)26に搭載されている。プロセッサ10が、場合によってはKGC(「ネイティブKGC」)を実行するか、KGC(「非ネイティブKGC」)を実行するために実行エンジン28が提供されうる。実行エンジン28は、プロセッサ集積回路24と通信しうる。一実施形態では、実行エンジン28と不揮発性メモリ22とが、1つの集積回路(例えばチップ上のシステム)に集積されうる。詳細には、チップ上の実行エンジン/不揮発性メモリシステムは、トラステッドプラットフォームモジュール(TPM)でもよい。この実施形態では、不揮発性メモリ22が、プロセッサ10のKGCソース12としても動作し、暗号認証ユニット14が設けらなくてもよい。一部の実施形態では、プロセッサ集積回路24内に、変更保護メモリ(例えばロックキャッシュ)が設けられてもよい。] 図3
[0021] 図4は、メモリコントローラ30と、ネイティブKGCを記憶しているメモリ32(不揮発性など)とを備えるシステムに、プロセッサ10が備えられる別の実施形態である。この場合、メモリ32はプロセッサ10の外にあり、このため、ネイティブKGCは(例えば、メモリコントローラ30あるいはプロセッサ10内の)暗号認証ユニット14内で暗号認証されうる。また、変更保護メモリ16(例えばプロセッサ10内のロックキャッシュ)も設けられうる。] 図4
[0022] メモリ32は、コンピュータシステムの基本入出力システム(BIOS)メモリでも、コンピュータシステムに設けられた別の不揮発性メモリでもよい。]
[0023] <アーキテクチャの変更のためのKGCへの遷移>
KGCは、正当な実体(信頼されたソース)から提供され、不正な変更から保護されているため、KGCは、プロセッサ製造業者によって信頼されうる。このため、KGCを使用して、プロセッサハードウェアにまだ実装されていないアーキテクチャの変更を実装することができる。KGCによって実装されるアーキテクチャの変更により、ユーザ(例えば、コードの作成者およびプロセッサを備えるコンピュータシステム)が、変更がハードウェアにコミットされる前にアーキテクチャの機能拡張を使用できる(または、アーキテクチャの機能削除がハードウェアにコミットされた後でもこの削除を使用できる)ようになる。]
[0024] 例えば、アーキテクチャの機能拡張(例えば新しい命令、既存の命令およびその実行環境の新機能、プロセッサ内部に設けられるか、プロセッサの近くに結合される新しいアクセラレータまたは他の機能ブロックなど)を、ハードウェアに実装する前に、これらをKGC内で実装することができる。アーキテクチャの機能拡張をKGCによって実装している間に、この機能拡張の定義に問題がみつかった場合、(例えば、機能拡張自体を変更することによって)機能拡張がハードウェアにコミットされる前に、問題を是正することができる。KGC実装を使用して、期待される機能拡張の利点(例えば高性能、低電力消費など)を予測することができる。その後、確信を持って機能拡張をハードウェアにコミットすることができる。また、同じ命令セットアーキテクチャを使用する競合企業が、新しい特徴を導入した場合、KGCを使用して、この特徴を実装し、競合企業による変更に迅速に追い着くことができる。]
[0025] アーキテクチャの機能削除(例えば、多用されていないか、多用されていないと考えられる命令の削除、不要であるか、不要であると考えられる従来の動作モードの削除)についても、KGCを使用して、削除された機能を実装することができる。機能が従来のコードで未だに使用されている場合でも、例えば、従来のコードを、パフォーマンスが低くなるが、正しく動作させることができる。したがって、削除した機能が使用されていても、機能削除が適切に動作することを確かめたうえで機能削除を実装することができる。]
[0026] KGCを使用してアーキテクチャの変更を実装するために、KGC実行に遷移するためのメカニズムが実装されうる。このメカニズムでは、プロセッサが、現在実行中のコードが、アーキテクチャの変更を使用することを検出し、これが検出されると、KGCを実行させうる。ここでは、現在実行中のコードを「ユーザプログラム」と呼ぶが、このプログラムは、特権コード(例えばオペレーティングシステムまたは他の特権コード)として実行していてもよい。この遷移は、ユーザプログラムが認識することなく行われ、このため、ユーザプログラムのために、アーキテクチャの機能拡張または機能削除がエミュレートされうる。]
[0027] このメカニズムは、アーキテクチャの変更を検出するために、プロセッサが使用可能なデータを含むようにプログラムされうるプログラマブルマップを有しうる。マップにプログラムされるデータは、変更の検出に応じて変わりうる。例えば、図5,6に示す一実施形態では、このデータには、命令の符号の全体または一部(例えばオペコード、オペコード修飾子、オペランドフィールドなど)が含まれうる。また、データに、プロセッサの現在の動作モードを示す、1つ以上の構成/制御レジスタの各種のモード指標が含まれてもよい。更に、図7,8に示す実施形態のように、データに、命令の実行中に生成されるアドレスまたはデータが含まれていてもよい。データに、命令の実行中に生成される、および/または実行中に発生しうる他の任意のイベント(例えば例外、特定の種類の例外、割り込み、特定の種類の割り込みなど)中に生成される、命令の符号およびデータ/アドレスの任意の組み合わせが含まれうる。プログラマブルマップは、どのような種類の記憶域または記憶域の組み合わせ(例えば、プロセッサが実行する命令によってアドレッシング可能なレジスタ、メモリアレイなど)でもよい。] 図5 図7
[0028] 図5は、検出された命令が実行に達する前に行われる遷移メカニズムの一実施形態を示すブロックである。図5には、(アーキテクチャの機能拡張に対応する)新しい命令を含むユーザプログラムが図示されている。同様の動作が、削除された命令、あるいはアーキテクチャの変更において動作が変更された命令を含むユーザプログラムで行われてもよい。また、図5には、KGC、ユーザプログラム状態40、およびKGC状態42も図示されている。ユーザプログラム状態40は、ユーザプログラムが認識可能なプロセッサのアーキテクチャの状態(例えばレジスタ値)を含む。KGC状態42は、KGCコードの実行中にのみ認識されるプロセッサの状態を含む。すなわち、ユーザプログラムコードは、KGC状態42の読み出しも書き込みもできない。このため、KGC状態42は、KGCにプライベートであり、プロセッサハードウェアが実装しない、エミュレート中のアーキテクチャの変更の一部として使用されうる。KGC状態42は、1つ以上のレジスタなどの、少なくとも一部のプロセッサ状態を含む。このレジスタは、例えば、KGCによって生成/使用されるデータを記憶するために使用されても、KGCが使用するために予約されているメモリへのポインタを記憶するために使用されても、この両方に使用されてもよい。また、レジスタは、KGCの実行を制御する各種の構成/制御データも記憶しうる。図5に示すように、ユーザプログラムはユーザプログラム状態40(矢印44)にアクセスできるが、KGC状態42にはアクセスできない。KGCは、ユーザプログラム状態(矢印48)のほかにKGC状態42(矢印46)にもアクセスできる。] 図5
[0029] ユーザプログラムには、図5に示すI1,I2,I3などの命令のストリームが含まれる。一般に、命令I1,I2,I3,I4,I5,I6は、プロセッサ10が実装する命令セットアーキテクチャに定義されている命令(「マクロ命令」と呼ばれる)である。命令の1つ(図5の「新しい命令」)が、KGCによって実装されるアーキテクチャの変更に従って新たに定義された命令である。つまり、この命令は、プロセッサハードウェアに実装されているアーキテクチャには定義されていない。この命令は、実行が許可されると、プロセッサ10に例外を発生させうる。あるいは、この命令は、既に定義されているが、KGCがエミュレートするアーキテクチャの変更の一部に含まれる新しい機能を使用してもよい。プロセッサ10には、この命令のために、例外(発生する場合)を阻止し、KGCをフェッチさせて実行させる、KGCへの実行前段階マッピング(矢印50)を有しうる。矢印50で示すKGCへの遷移により、KGC状態42が有効となり、KGC内で実行中の命令からKGC状態42が認識可能となる。場合によっては、KGCが、指定された機能を実装できることが保証されるが、ユーザプログラムのために例外を発生させるが、KGCの実行には不要なイベントが、KGCの実行中に例外を発生させることを保証するために、プロセッサ10が、KGCの実行のために特権レベルを上げてもよい。このため、特権の向上が、特定のリソース、全体的な特権保護方式の特定の一部のみに限定されうる。] 図5
[0030] また、KGCは、図5に示すように、命令KGC I1〜INのストリームも含む。KGC命令も、プロセッサ10が実装する命令セットアーキテクチャで定義されている(KGCがエミュレートするアーキテクチャの変更を含まない)マクロ命令であってもよい。KGC命令は、実行されると、プロセッサ10に実装されていないアーキテクチャの変更をエミュレートする。KGCは、通常、実行を、新しい命令の後の命令(例えば図5の15)でユーザプログラムに戻させる命令で終了するが、別の点で実行を続けてもよい(例えば、複数の命令がエミュレートされた場合にユーザプログラムの後に続く命令、エラーが検出された場合に例外または他のエラー処理ルーチンなど)。] 図5
[0031] 同様に、KGCが、プロセッサ10に実装されているアーキテクチャの変更によって削除されている機能をエミュレートすることもできる。例えば、ある命令がアーキテクチャから削除されている場合、従来のユーザプログラムが正しく動作するように、KGCがその命令をエミュレートしてもよい。更に、プロセッサ10が命令を不適切に実装している場合(例えば、プロセッサハードウェアでバグが見つかった場合など)に、KGCを使用して、正常動作を行わせることもできる。]
[0032] 図6は、KGCへの命令の実行前マッピングを実装しうるプロセッサ10の一実施形態のブロック図である。図に示した実施形態では、プロセッサ10は、命令キャッシュ(ICache)60、フェッチユニット62、デコードユニット64、実行コア66、ユーザ状態記憶域68、KGC状態記憶域70、およびプログラマブルマップ72を有する。フェッチユニット62はICache60とデコードユニット64とに結合され、デコードユニット64はプログラマブルマップ72と実行コア66とに結合されている。更に、実行コア66は、ユーザ状態記憶域68とKGC状態記憶域70とに結合されている。] 図6
[0033] フェッチユニット62が、ICache60から命令をフェッチし、フェッチされた命令をデコードユニット64に提供して、プロセッサ10は、ユーザプログラムを実行する。デコードユニット64は、命令をデコードし、デコードした命令を実行のために実行コア66に提供しうる。場合によっては、デコードユニット64は、オペランドリード要求をユーザ状態記憶域68(KGCが実行中の場合はKGC状態記憶域70)に提供しうる。]
[0034] また、デコードユニット64は、プログラマブルマップ72に結合され、プログラマブルマップ72は、KGC実行への遷移を発生させる1つ以上の命令を識別するデータを含むようにプログラムされうる。プログラマブルマップ72は、プロセッサ10の電源投入時にプログラムされ、その後、任意のユーザプログラムが実行される。プログラマブルマップ72は、プログラムのために命令によってアドレス参照可能でも、ハードウェア回路網が、プロセッサ10に命令を実行させる準備の一環として、指定されたコンピュータシステム位置からマップを読み出して、プログラマブルマップ72に格納してもよい。]
[0035] この実施形態では、プログラマブルマップ72に記憶されているデータは、KGC実行への遷移を発生させる命令のすべてまたは一部を識別しうる。例えば、命令のオペコードフィールド、修飾子、オペランド指示子などが使用されうる。また、一部の実施形態では、各種のモード指標が、プログラマブルマップのデータに含まれてもよい。]
[0036] デコードユニット64が、プログラマブルマップ72で指定されている命令を検出すると、デコードユニット64は、その命令(と、ユーザプログラムコードストリーム内の後続の命令)を廃棄し、フェッチユニット62に信号を送信してKGCをフェッチさせる(図6の「KGCフェッチ」信号)。例えば、ICache60内でネイティブKGCがロックされうる。別の実施形態では、ネイティブKGCは、同じチップまたは同じMCM上の不揮発性メモリに存在しても、別個のシステムメモリに存在してもよい。別の実施形態では、デコードユニット64は、図3に示すような外部の実行エンジンに、非ネイティブKGCを実行させるように信号を送信してもよい。] 図3 図6
[0037] デコードユニット64は、どのようなデコード回路網を有しうる。デコードユニットは、命令をデコードするように構成された1つ以上のハードウェアデコーダを有しうる(複数のデコーダが提供される場合、異なる命令を並列にデコードしうる)。また、デコードユニットは、より複雑な命令のためにマイクロコードルーチンをディスパッチするように構成されたマイクロコードユニットも有しうる。]
[0038] 実行コア66は、どのような実行構成(例えばスーパースカラ、スーパーパイプライン化、インオーダー、アウトオブオーダーなど)を有していてもよい。また、実行コア66は、ネイティブKGCが実行中の場合のみ、KGC状態記憶域70へのアクセスを許可しうる。ユーザ状態記憶域68とKGC状態記憶域70は、それぞれのどのような半導体記憶装置(例えばレジスタ、レジスタファイル、メモリアレイなど)を有してもよい。]
[0039] 図7は、検出された(KGC実行への遷移を発生させる)命令の実行後、または検出された命令の実行中に行われる遷移メカニズムの別の実施形態を示すブロック図である。図5と同様に、図7はユーザプログラムとKGCとを示す。この実施形態では、アーキテクチャの変更を実装する命令が実行され、その実行中に発生するイベントが、KGCを実行すべきことの検出に使用される。また、図7には、図5と同様に、ユーザプログラム状態40とKGC状態42とも図示されている。図5と同様に、ユーザプログラムはユーザプログラム状態40(矢印44)にアクセスできるが、KGC状態42にはアクセスできない。KGCは、ユーザプログラム状態(矢印48)のほかにKGC状態42(矢印46)にもアクセスできる。] 図5 図7
[0040] ユーザプログラムには、図7に示すI1,I2,I3などの命令のストリームが含まれる。一般に、命令I1,I2,I3,I4,IO命令,I5,I6は、マクロ命令である。IO命令は、メモリマップドI/O、またはいわゆるイン/アウトI/O(IOIO)のいずれかの入出力(I/O)にマップする命令である。IOIOは、x86命令セットのIN命令およびOUT命令に対応する。一般に、IOIO命令は、I/Oサイクルを発生させるどのような命令でもよく、I/Oサイクルは、メモリアドレス空間とは別個のI/Oアドレス空間で発生し、プロセッサによって「別個である」と認識される。IO命令は、KGC実行への遷移を発生させるトリガイベント(矢印80)を介して、実行中のプロセッサ10によって検出されうる。] 図7
[0041] 一実装では、トリガイベントは、IO命令の実行中に生成されるアドレスでもよい。別の実施形態では、実行中に読み出されるかまたは書き込まれるデータがトリガイベントでも、IO命令の実行中の他のどのようなイベントがトリガイベントでもよい。別の実施形態では、命令は、プロセッサ10がトリガイベントとして検出できるイベントを発生させるものであれば、必ずしも入出力命令でなくてもよい。ほかのトリガイベントとしては、タイマー切れ、エラー検出(ECCエラーなど)、あるいは、マシン状態の他の任意の検出可能な変化などが挙げられる。]
[0042] 図8は、トリガイベントに基づいて、実行中または実行後に、命令のKGCへのマッピングを実装しうるプロセッサ10の別の実施形態のブロック図である。図6の実施形態と同様に、図8の実施形態は命令キャッシュ(ICache)60、フェッチユニット62、デコードユニット64、実行コア66、ユーザ状態記憶域68、KGC状態記憶域70、およびプログラマブルマップ72を備える。フェッチユニット62はICache60とデコードユニット64とに結合され、デコードユニット64は実行コア66に結合されている。更に、実行コア66は、ユーザ状態記憶域68とKGC状態記憶域70とに結合されている。] 図6 図8
[0043] 図8の実施形態では、プログラマブルマップ72に結合されており、フェッチユニット62(または外部実行エンジン)にフェッチKGC指標を生成するのは実行コア66である。プログラマブルマップ72のデータは、KGCへの遷移を発生させる命令の実行中のトリガイベントである、アドレス、アドレス範囲、データ、データ範囲、例外、割り込みなどを識別しうる。また、このデータには、KGCへの遷移を発生させる命令を識別する実行生成データと共に使用される(あるいは、実行生成データの代わりに使用される)、命令を識別するデータ(例えばオペコード、および他の符号)も含まれてもよい。上で説明したように、このデータには、各種のモード指標が含まれてもよい。] 図8
[0044] KGCのフェッチ/実行を指示する信号を送信するほか、実行コア66は、トリガイベントに対応する命令に同期しうる(トリガした命令および先行する全命令が実行を完了するまで、第1のKGC命令の実行を待機し、KGC実行が完了するまで、ユーザプログラム内のトリガした命令の後の続に続く命令を実行しない)。また、実行コア66は、パイプラインの実行段階前に、デコードユニット64および他の任意のユニットに、ユーザプログラム命令をパージさせても、KGCフェッチ信号を使用してパージが指示されてもよい。
KGCの他の用途]
[0045] 前のセクションでは、アーキテクチャの変更を実装するためのKGCの使用について説明した。KGCの他の用途も考察される。]
[0046] 例えば、図9は、1つ以上の汎用(GP)コア92A〜92Nと、1つ以上の特殊用途(SP)コア94A〜94Mとを有し、これらがすべて1つのシリコン基板に集積されている(または、別の実装ではMCMに搭載されている)集積回路90を示す。GPコア92A〜92Nは、プロセッサ10と同様の、命令セットアーキテクチャに定義されている命令を実行するように設計されたプロセッサでもよい。SPコアは、アクセラレータ、追加機能または他のデバイスでもよい。例えば、SPコアは、グラフィック操作のために最適化されたグラフィック処理ユニット(GPU)、暗号化タスクを実行するように構成された暗号アクセラレータ、トラステッドプラットフォームモジュール、電力管理用に使用されうる低電力消費/低パフォーマンスのプロセッサコア、および他の所望のデバイスであってもよい。複数のSPコアが搭載される場合、SPコアは相互に異なっていてもよい。一般に、SPコア94A〜94Mは、GPコア92A〜92Nに追加で設けられる、どのような望ましい回路網を含んでもよい。] 図9
[0047] 図9の実施形態のKGCは、GPコア92A〜92NによるSPコア94A〜94Nへのアクセスを制御するデバイスマネージャ96でもよい。KGCは、SPコア94A〜94Mにアクセスするために、GPコア92A〜92Nで実行中のユーザプログラムによって使用されうるアプリケーションプログラミングインタフェース(API)を提供しうる。このため、SPコア94A〜94Mは、SPコアへのアクセスを含めて変更されるが、GPコア92A〜92N(およびユーザプログラム)を、この変更から切り離すことができる。また、KGCデバイスマネージャ96は、タスクの優先度の決定と、GPコア92A〜92M間でのSPコア94A〜94Mの共有も処理しうる。例えば、SPコア94A〜94Mが、優先度の高いタスクが要求されたときに、優先度の低いタスクを実行しているとする。KGCデバイスマネージャ96はこのSPコアに割り込み、優先度の低いタスクに対応する状態を保存して、優先度の高いタスクを開始する。KGCデバイスマネージャ96は、異なるタスクの状態が、関係のないユーザプログラムに公開されないように、タスクの状態を保持するための安全な記憶位置を有しうる。つまり、あるプログラムの状態が、KGCによって、別のプログラムから隠される。このため、KGCデバイスマネージャ96は、セキュリティを提供することができる。例えば、SPコアが暗号デバイスである場合、暗号化に使用するキーやその他の機密データを、関係のないプロセスから隠すことができる。また、KGCデバイスマネージャ96は、SPコアをエミュレートして、このSPコアの除去を可能にしたり、あるいは要求の受信時に物理コアがすべて使用されている場合に、仮想コアを実現する。] 図9
[0048] また、KGCデバイスマネージャ96は、集積回路90内でどの機能を有効にし、どの機能を無効にするかも制御しうる。このような機能制御には、さまざまな用途がある。例えば、購入した機能を有効にし、購入期限が切れたときに、この機能を無効にするプリペイドモデルをサポートすることができる。最初の販売時に機能を無効にし、利用者が追加で支払を行った場合に、この機能を有効にすることができる。]
[0049] GPコア92A〜92Nからの要求に応答するデバイスマネージャ94としてのKGCの一実施形態の動作の例が、図10のフローチャートに示される。図10ではブロックが理解しやすいように図示されているが、順序を変更してもよい。KGCは、実行されると、図10のフローチャートを実装する命令を有しうる。] 図10
[0050] KGCは、要求されたコアが集積回路90に存在するかどうかを判定しうる(判定ブロック130)。要求されたコアが存在しない場合(例えば、コアが除去されているか、集積回路90の後の設計に含まれていない場合、判定ブロック130の「いいえ」の線)、KGCは、存在しないコアをエミュレートしうる(ブロック132)。あるいは、要求されたコアが、集積回路90に存在しないが、同等のハードウェアが、プロセッサを含むコンピュータシステムの他の部分で使用可能な場合、KGCは、要求されたタスクを実行するために、外部ハードウェアと通信しうる。KGCは、有無の確認とエミュレーションを行うことによって、SPコアが存在しない場合であっても、SPコア94A〜94Mを使用するプログラムを機能させることができる。]
[0051] 要求されたコアが集積回路90に存在する場合、(判定ブロック130の「はい」の線)、KGCは、要求されたコア94A〜94Mが使用可能かどうかを判定しうる(判定ブロック134)。所定のタイプのコアが複数存在し、要求されたタイプのコア94A〜94Mのいずれか使用可能である場合(例えば有効であり、アイドルの場合)、そのコア94A〜94Mがタスクの実行に割り当てられうる。要求されたコア94A〜94Mが使用可能である場合(判定ブロック134の「はい」の線)、KGCは、要求されたタスクを実行するようにコアをプログラムしうる(ブロック136)。タスクが終了すると(判定ブロック138の「はい」の線)、KGCは要求側に通知しうる(ブロック140)。タスクの終了の判定は、さまざまな形をとることができる。例えば、KGCが割り当てたコア94A〜94Mをポーリングしても、割り当てたコアが終了時に割り込みをアサートしてもよい。終了したタスクが、コアの別のタスクを剥奪した場合(判定ブロック142の「はい」の線)、KGCは、剥奪されたタスクのタスク状態を安全な記憶域から安全に転送し(ブロック144)、記憶されている状態から要求を実行するようにコアをプログラムし(ブロック136)、このタスクが上で説明したように実行を続けうる。安全な記憶域は、KGC以外のコードからは隠されているKGC割当のデータ記憶域(例えば、データキャッシュ記憶域、書き込み可能NVRAM記憶域などにある)であってもよい。終了したタスクがタスクを剥奪しておらず、(安全な記憶域内に)実行を待機中のタスクが存在する(判定ブロック146の「はい」の線)場合、KGCは、待機中のタスクのタスク状態を安全な記憶域から安全に転送し(ブロック144)、待機中のタスクを実行するようにコアをプログラムし(ブロック136)、このタスクが上で説明したように実行されうる。]
[0052] 要求されたコアが使用できない場合(判定ブロック134の「いいえ」の線)、KGCは、要求されたコアが、要求されたタスクよりも優先度の低いタスクを実行しているかどうかを判定しうる(判定ブロック148)。優先度は、どのような所望の優先度方式を使用してタスクに割り当ててもよい。優先度方式は、要求されたタスクに関連付けられていても(例えば、ある種類のタスクが、他の種類のタスクよりも優先度が高いなど)、または要求を発生させたユーザプログラムの相対的な優先度に基づいて割り当てられてもよい。優先度の低いタスクがコア94A〜94Mで実行されている場合(判定ブロック148の「はい」の線)、KGCは、優先度の高いタスクを実行するために、優先度の低いタスクを剥奪しうる(ブロック150)。KGCは、剥奪したタスクの状態が、他のユーザプログラムから隠される(開始したユーザプログラム自身からさえも隠される)ように、この状態を安全な記憶域に安全に転送しうる(ブロック152)。KGCは、要求を実行するようにコアをプログラムし(ブロック136)、このタスクが上で説明したように実行されうる。優先度の低いタスクを実行しているコアがない場合(判定ブロック148の「いいえ」の線)、KGCは、安全な記憶域にタスク要求状態を記憶し、コアが使用可能になるまで待機する(ブロック154)。別の実施形態では、KGCが、必要に応じて要求されたコアをエミュレートしてもよい。]
[0053] 考えられるKGCの別の用途は、x86(あるいは、IA−32、AMD−64(登録商標)などの拡張)命令セットに関連する。x86命令セットは、4レベルの特権方式によって特権を制御している。最も特権の高いレベルは、リング0と呼ばれ、多くの場合、オペレーティングシステムのカーネル動作のために必要となる。しかし、リング0はパーティション化されていない。リング0で動作しているどのタスクも、そのタスクがアクセスすべきではない状態を含め、マシンのどの状態にも影響する(effect)ことができる。このようなリング0の構成により、不正なコードが、関係のない操作に問題を引き起こすことが可能となり、セキュリティ上の懸念となっている。]
[0054] KGCは、リング0をパーティション化することにより、この影響に対処するために使用することができる。図11は、パーティションを示し、円100で示されるリング0と、パーティションを示す線102A〜102Cが図示されている。あるパーティションに属するコードが、そのパーティションにはないリソースにアクセスしようとした場合、KGC104は、そのアクセスを傍受して、このアクセスが許されるかどうかを判定しうる。例えば、パーティションから別のパーティションへのアクセスが、破線矢印106で示される。アクセスが許可される代わりに、アクセスがKGC104に転送されうる(実線矢印108)。アクセスが許可される場合、KGC104は、要求側に代わってアクセスを実行しうる(実線矢印110)。このようにして、パーティションを相互に分離することができる。パーティションに悪意のあるコードが侵入した場合、そのパーティションは影響を受けるが、ほかのパーティションへの影響を低く抑えることができ、場合によっては影響をなくすことができる。] 図11
[0055] 図11に示すパーティション化は、さまざまな方法で実装することができる。例えば、異なるメモリ範囲を異なるパーティションに割り当て、パーティションが、プログラマブルマップ72にプログラムされてもよい。実行中のコードのパーティションの外にあるメモリアドレスが生成されると、KGCへの遷移が発生してもよい。同様に、構成/制御レジスタ状態をパーティションに分割し、許容されないレジスタをオペランドとして検出するようにプログラマブルマップ72をプログラムすることによって、現在のパーティションに基づいて、構成/制御レジスタへのアクセスを制限してもよい。] 図11
[0056] KGCを使用して、新しいアーキテクチャの機能を実装することもできるが、場合によっては、KGC単独では、ハードウェア実装が提供する所望のパフォーマンスを提供できないこともある。一実施形態では、KGCは、プロセッサと共に集積回路に含まれるプログラマブルロジックユニットへのインタフェースを管理しうる。KGCに割り当てられる機能の少なくとも一部が、プログラマブルロジックユニット内に実装され、このため、「ハードウェア様」の高速で実行されうる。残りの機能はKGC自体に実装されうる。]
[0057] 図12は、プロセッサ10(ユーザ状態記憶域68とKGC状態記憶域70を備える)と、プログラマブルロジックユニット122とを有する集積回路120の一実施形態のブロック図である。また、図12には、KGCと、少なくとも1つのプログラマブルロジック構成124Aとを記憶しているKGCソース12も図示されている。場合によっては、プログラマブルロジック構成124Bなどの、追加のプログラマブルロジック構成も記憶されている。] 図12
[0058] プログラムインタフェース(図12の「プログラム」)を使用して、プログラマブルロジック構成がプログラマブルロジックユニット122にロードされうる。プログラムインタフェースは、集積回路120の外部入出力から切り離されており、このため、プロセッサ10で実行中のKGCのみがプログラムすることができる。KGCは、KGCソース12から構成124Aまたは124Bを読み出し、プログラムインタフェースを介してプログラマブルロジックユニット122にこの構成を書き込みうる。] 図12
[0059] 一部の実装では、プログラマブルロジックユニット122の構成が起動時に選択されてもよく、KGCは、起動時に構成をプログラマブルロジックユニット122にロードし、その後もこの構成を保持しうる。別の実装では、KGCソース12から別の構成を選択して、プログラマブルロジックユニット122を再プログラムすることにより、プログラマブルロジックユニット122の構成が動作中に変更されてもよい。このような実装では、KGCによって実行中のタスクに基づいて、プログラマブルロジックユニット122の動作が変わりうる。例えば、プログラマブルロジックユニット122を利用する2つの演算量の多いタスクがKGCに含まれる場合、頻繁に使用されるタスクの構成が、プログラマブルロジックユニット122にロードされうる。(プログラマブルロジックユニット122にロードされていない)他のタスクが要求されると、プログラマブルロジックユニット122が変更されうる。あるいは、他のタスクが頻繁に要求される場合にのみ、プログラマブルロジックユニット122が変更されてもよく、プログラマブルロジックユニット122の構成を変更すべきと判定されるまで、KGCはソフトウェア内でそのタスクを実行しうる。]
[0060] プログラマブルロジックユニットは、入力(図12の[0:n])を受け取り、出力(図12のOut[0:m])を生成しうる。入力はKGC状態記憶域70から供給され、出力がKGC状態記憶域70で受信され、KGCがプログラマブルロジックユニット122を動作させ、プログラマブルロジックユニット122から結果を受け取るメカニズムが提供される。例えば、入力と出力が、KGC状態記憶域70内のレジスタのビットにマップされうる。] 図12
[0061] プログラマブルロジックユニット122は、どのような種類の非永続的なプログラマブルロジックを有してもよい。例えば、フィールドプログラマブルゲートアレイ(FPGA)またはコンプレックス合プログラマブルロジックデバイス(CPLD)技術を使用することができる。フラッシュ、消去可能リードオンリーメモリまたはランダムアクセスメモリ技術が、プログラマブルロジックユニット122に使用されてもよい。]
[0062] 上記の開示を完全に理解できれば、数多くの変形例および変更例が当業者にとって明らかであろう。下記の特許請求の範囲は、このような変形例および変更例を全て包含するものと解釈されることが意図される。]
[0063] 本発明は、一般に、プロセッサおよびコンピュータシステムに利用可能である。]
权利要求:

請求項1
集積回路であって、少なくとも1つのプロセッサコアと、少なくとも1つの他の回路と、実行のために前記プロセッサコアにノウングッドコード(KGC)を提供するように構成されたKGCソースとを備え、前記KGCは前記他の回路のためのインタフェースコードを含み、これにより前記少なくとも1つのプロセッサコアで実行中のアプリケーションが前記KGCを介して前記少なくとも1つの他の回路とインタフェースする、集積回路。
請求項2
前記KGCは前記少なくとも1つの他の回路へのアクセスを管理するように構成されたデバイスマネージャを含む、請求項1に記載の集積回路。
請求項3
前記少なくとも1つのプロセッサコアは複数のプロセッサコアを含み、前記デバイスマネージャは前記複数のプロセッサコアの前記少なくとも1つの他の回路へのアクセスを管理するように構成されている、請求項2に記載の集積回路。
請求項4
前記デバイスマネージャは前記少なくとも1つの他のデバイスからの前記複数のプロセッサコアのうちの1つで実行中のプログラムに関連する状態を安全に保存し、別のプログラムに関連する状態を前記少なくとも1つの他の回路にロードするように構成されている、請求項3に記載の集積回路。
請求項5
少なくとも1つのプロセッサコアと、少なくとも1つの他の回路とを有する集積回路において実行される方法であって、前記プロセッサコアでノウングッドコード(KGC)を実行するステップを含み、前記KGCは前記他の回路のためのインタフェースコードを含み、これにより前記少なくとも1つのプロセッサコアで実行中のアプリケーションが前記KGCを介して前記少なくとも1つの他の回路とインタフェースする、方法。
請求項6
前記KGCは前記少なくとも1つの他の回路へのアクセスを管理するように構成されたデバイスマネージャを含み、前記少なくとも1つのプロセッサコアは複数のプロセッサコアを含み、前記複数のプロセッサコアの前記少なくとも1つの他の回路へのアクセスを管理するステップをさらに含む、請求項5に記載の方法。
請求項7
アクセスを管理する前記ステップは前記少なくとも1つの他のデバイスからの前記複数のプロセッサコアのうちの1つで実行中のプログラムに関連する状態を安全に保存するステップと、別のプログラムに関連する状態を前記少なくとも1つの他の回路にロードするステップとを含む、請求項6に記載の方法。
請求項8
前記少なくとも1つの他の回路はプログラマブルロジックユニットを有し、前記KGCを実行する前記ステップは前記集積回路の初期化時に前記プログラマブルロジックユニットに設定をロードするステップを含む、請求項5に記載の方法。
請求項9
ノウングッドコード(KGC)を記録したコンピュータアクセス可能記録媒体であって、少なくとも1つのプロセッサコアと少なくとも1つの他の回路とを有する集積回路で実行されると、前記他の回路のためのインタフェースコードを提供する命令を含み、これにより前記少なくとも1つのプロセッサコアで実行中のアプリケーションが前記KGCを介して前記少なくとも1つの他の回路とインタフェースする、記録媒体。
請求項10
前記KGCは前記少なくとも1つの他の回路へのアクセスを管理するように構成されたデバイスマネージャを含み、前記少なくとも1つのプロセッサコアは複数のプロセッサコアを含み、前記KGCは前記複数のプロセッサコアの前記少なくとも1つの他の回路へのアクセスを管理する、請求項9に記載のコンピュータアクセス可能記憶媒体。
請求項11
プロセッサであって、少なくとも1つの命令であって、前記プロセッサが実装している命令セットアーキテクチャのアーキテクチャの変更が定義されているが、前記プロセッサは前記変更を実装してない命令を識別するデータを記憶するように構成されるプログラマブルマップと、前記プログラマブルマップに結合されており、前記命令を検出して、ノウングッドコード(KGC)への遷移を発生させるように構成された回路網とを備え、前記KGCは不正な変更から保護されており、正当な実体から提供され、前記KGCは、実行されると前記変更をエミュレートするコードを含む、プロセッサ。
請求項12
前記回路網は前記命令が前記プロセッサでの実行段階に達する前にKGCへの前記遷移を発生させるように構成されている、請求項11に記載のプロセッサ。
請求項13
少なくとも1つの命令を識別するデータをプロセッサにプログラムするステップであって、前記少なくとも1つの命令は、前記プロセッサが実装している命令セットアーキテクチャのアーキテクチャの変更が定義されている少なくとも1つの命令を含むところのステップと、前記データに応答してコードシーケンス内で前記少なくとも1つの命令を検出するステップと、ノウングッドコード(KGC)への遷移を発生させるステップとを含み、前記KGCは不正な変更から保護されており、正当な実体から提供され、前記KGCは実行されると前記変更をエミュレートするコードを含む、方法。
請求項14
検出する前記ステップと遷移を発生させる前記ステップは命令の実行中に実行される、請求項13に記載の方法。
类似技术:
公开号 | 公开日 | 专利标题
Lipp et al.2018|Meltdown
US20180045189A1|2018-02-15|System and Method for Processor-Based Security
US9767284B2|2017-09-19|Continuous run-time validation of program execution: a practical approach
US9846787B2|2017-12-19|System and method for implementing a trusted dynamic launch and trusted platform module | using secure enclaves
Ferraiuolo et al.2017|Komodo: Using verification to disentangle secure-enclave hardware from software
US9767271B2|2017-09-19|System and method for validating program execution at run-time
US10152602B2|2018-12-11|Protecting state information for virtual machines
US10592436B2|2020-03-17|Memory initialization in a protected region
US10810321B2|2020-10-20|Secure public cloud
US9805198B2|2017-10-31|Event-based apparatus and method for securing bios in a trusted computing system during execution
US10628612B2|2020-04-21|Secure public cloud with protected guest-verified host control
US8856789B2|2014-10-07|Facilitating execution of a self-modifying executable
US10558588B2|2020-02-11|Processors, methods, systems, and instructions to support live migration of protected containers
US7171539B2|2007-01-30|Apparatus and method for controlling access to a memory
US7487367B2|2009-02-03|Apparatus and method for managing access to a memory
US9697142B2|2017-07-04|Execution-aware memory protection
US7383587B2|2008-06-03|Exception handling control in a secure processing system
US8443423B2|2013-05-14|Secure information processing
US7124274B2|2006-10-17|Virtual to physical memory address mapping within a system having a secure domain and a non-secure domain
US8578483B2|2013-11-05|Systems and methods for preventing unauthorized modification of an operating system
JP4423012B2|2010-03-03|マルチドメインプロセッサのための診断データ捕捉制御
US7849310B2|2010-12-07|Switching between secure and non-secure processing modes
US8407476B2|2013-03-26|Method and apparatus for loading a trustable operating system
US7117284B2|2006-10-03|Vectored interrupt control within a system having a secure domain and a non-secure domain
US7370210B2|2008-05-06|Apparatus and method for managing processor configuration data
同族专利:
公开号 | 公开日
US20140129810A1|2014-05-08|
KR20100102666A|2010-09-24|
CN101999123A|2011-03-30|
US8612729B2|2013-12-17|
KR101538749B1|2015-07-22|
TW200937293A|2009-09-01|
US9058163B2|2015-06-16|
EP2223257A1|2010-09-01|
US20100174890A1|2010-07-08|
WO2009078913A1|2009-06-25|
JP5410445B2|2014-02-05|
引用文献:
公开号 | 申请日 | 公开日 | 申请人 | 专利标题
法律状态:
2011-12-03| A621| Written request for application examination|Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20111202 |
2013-05-31| A977| Report on retrieval|Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20130531 |
2013-07-04| A131| Notification of reasons for refusal|Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20130703 |
2013-10-03| A521| Written amendment|Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20131002 |
2013-10-11| TRDD| Decision of grant or rejection written|
2013-10-17| A01| Written decision to grant a patent or to grant a registration (utility model)|Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20131016 |
2013-11-14| A61| First payment of annual fees (during grant procedure)|Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20131106 |
2013-11-15| R150| Certificate of patent or registration of utility model|Ref document number: 5410445 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
2016-11-01| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 |
2017-11-07| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 |
2018-11-06| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 |
2019-11-05| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 |
2020-10-30| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 |
2021-10-29| R250| Receipt of annual fees|Free format text: JAPANESE INTERMEDIATE CODE: R250 |
优先权:
申请号 | 申请日 | 专利标题
[返回顶部]